Был тут случай недавно - пишет мне товарищ, дескать, что это мы пост разместили с инфой, которая под NDA. А откуда мы должны знать, что находится под NDA, а что не под NDA? И вообще с какой стати все эти заморочки с NDA? Я вообще на тему продуктов чьих-то NDA никогда не подписывал и подписывать не собираюсь. А если появляется утечка с новыми возможностями продукта или компании - это никакой нахрен не слив инфы под NDA, а самая обычная и уже набившая оскомину реклама - радуйтесь.

Или вот приходит нам рассылка про новую версию vCloud Director, а внизу написано:

***** Confidential Information ***** 
Do not forward information about this program or release to anyone outside of those directly involved with beta testing. This information is highly confidential.

Information contained in this email, including version numbers, is not a commitment by VMware to provide or enhance any of the features below in any generally available product.

Или вот NVIDIA пишет:

Обращаю ваше внимание, что информация брифинга находится под NDA до 17:00 по Москве вторника, 23-го июля.

И чо? А если я им в письме напишу, что им нельзя мыться 3 месяца - они будут этот наказ соблюдать?

Так что, уважаемые вендоры, надеюсь, вам понятна позиция VM Guru с вашими NDA. Если мы их не подписывали - не пишите нам ничего на эту тему, так как эти письма отправляются прямиком в трэш по ключевому слову "NDA".

Вон у Apple тоже, конечно, утечки бывают, но в целом-то - хрен узнаешь, когда этот новый айфон выйдет. Поэтому в этом посте мы с удовольствием расскажем о новых возможностях VMware vSphere 5.5 на основе информации, взятой из сети интернет (также об этом есть на блоге Андрея и Виктора - http://vmind.ru/2013/08/15/chego-zhdat-ot-vmware-vsphere-5-5/). Естественно, не все из этих фичей могут оказаться в релизной версии, и это, само собой, не полный их список.

New OS Support

Наряду с поддержкой Windows 8.1 (ожидается в VMware View 5.5) будут поддерживаться последние релизы гостевых ОС Linux: Ubuntu, Fedora, CentOS, OpenSUSE и другие дистрибутивы.

VMware Hardware Version 10

Теперь появится новое поколение виртуального аппаратного обеспечения версии 10. Это добавит новых возможностей виртуальным машинам с точки зрения динамических сервисов виртуализации. Для редакции vSphere Enterprise Plus будет поддерживаться до 128 vCPU.

Administrative UI (Web Client)

Новая версия веб-клиента vSphere Web Client теперь является единственным средством управления инфраструктурой виртуализации.

• Улучшенный интерфейс, большое количество фильтров и вкладка "recent objects", позволяющая получить быстрый доступ к объектам.
• Улучшения по времени отклика интерфейса и возможность управлять большим числом объектов.

vSphere Replication - теперь доступны следующие возможности по репликации виртуальных машин:

• Возможность репликации виртуальных машин между кластерами для машин не с общими хранилищами (non-shared storage).
• Поддержка нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
• Storage DRS Interoperability - возможность реплицируемых машин балансироваться по хранилищам средствами технологии Storage vMotion без прерывания репликации.
• Simplified Management - улучшенная интеграция с vSphere Web Client, что позволяет мониторить процесс репликации в различных представлениях vCenter.
• Поддержка технологии VSAN (см. ниже) - теперь машины на таких хранилищах поддерживаются средствами репликации.
• vCenter Orchestrator - теперь это средство автоматизации существенно оптимизировано в плане масштабируемости и высокой доступности. Разработчики теперь могут использовать упрощенные функции диагностики в vCenter Orchestrator client.

Virtual SAN

О возможностях VMware Distributed Storage и vSAN мы уже писали вот в этой статье. Virtual SAN - это полностью программное решение, встроенное в серверы VMware ESXi, позволяющее агрегировать хранилища хост-серверов (SSD и HDD) в единый пул ресурсов хранения для всех хостов, что позволяет организовать ярусность хранения с необходимыми политиками для хранилищ.

Поддержка томов vVOL

Также мы писали о поддержке виртуальных томов vVOL - низкоуровневых хранилищ для каждой из виртуальных машин, с которыми будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Проще говоря, VMDK-диск машины можно будет хранить как отдельную сущность уровня хранилищ в виде vVOL, и с ней можно будет работать отдельно, без влияния на другие ВМ этого массива.

VMware Virtual Flash (vFlash)

О возможностях VMware Virtual Flash (vFlash) мы уже писали вот в этой статье. vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.

Virtual Machine File System (VMFS)

Теперь VMware vSphere 5.5 поддерживает vmdk-диски объемом более 2 TБ. Теперь объем виртуального диска машины может быть размером до 64 ТБ. Несколько больших файлов теперь могут храниться в одном vmdk. Это поддерживается только для VMFS 5.

vCloud Director

Теперь продукт доступен как виртуальный модуль (Virtual Appliance) - можно использовать как встроенную так и внешнюю БД. Этот модуль по-прежнему не будет рекомендован для продакшен-среды. Рекомендуют использовать его для апробации решения.

Был существенно улучшен Content Catalog:

• Улучшена производительность и стабильность синхронизации
• Расширяемый протокол синхронизации
• Возможность самостоятельной загрузки элементов каталога (OVF)

Кроме того, для интерфейса управления теперь поддерживается больше браузеров и ОС (в том числе поддержка Mac OS).

vCloud Networking & Security

В составе vSphere 5.5 этот продукт будет иметь следующие улучшения:

• Улучшенная поддержка Link Aggregation Control Protocol (LACP) - теперь поддерживается 22 алгоритма балансировки и до 32 физических соединений в агрегированном канале.
• Улучшения производительности и надежности агрегированного канала.

Кроме того, вместо vCloud Networking and Security с октября выходит новый продукт VMware NSX.

Security Features

Теперь появится распределенный сетевой экран (Distributed Firewall), являющийся одним из ключевых компонентов концепции Software Defined Datacenter. Он работает на уровне гипервизора каждого из хостов VMware ESXi, а на уровне централизованной консоли доступен мониторинг проходящих пакетов от абсолютно каждой виртуальной машины.

Политики этого сетевого экрана определяются на уровне VXLAN, поэтому нет нужды оперировать с ним на уровне IP-адресов. Ну и так как поддержка этого распределенного фаервола реализована на уровне гипервизора - то политики перемещаются вместе с виртуальной машиной, если она меняет хост средствами vMotion.

Более подробно об этом можно прочитать тут.

vCenter Site Recovery Manager

Теперь vCenter SRM будет поддерживать технологию vSAN вместе с vSphere Replication, работать с технологиями Storage DRS и Storage vMotion. Кроме того, добавлена поддержка нескольких точек восстановления реплик (Multi-Point-In-Time snapshots) при исполнении плана аварийного восстановления.

VMware vCenter Multi-Hypervisor Manager (MHM) 1.1

Об этом продукте мы уже писали вот тут. Теперь он будет поддерживать гипервизор Microsoft Hyper-V 3.0 в Windows Server 2012 R2 (а также более ранние его версии). Также появилась возможность холодной миграции ВМ с хостов Hyper-V на VMware vSphere.

Single Sign-On 2.0 (SSO)

В новой версии единого средства аутентификации продуктов VMware теперь появится улучшенная и новая поддержка следующих компонентов:

• vSphere
• vCenter Orchestrator
• vSphere Replication
• vSphere AppHA (новый продукт, который будет анонсирован на VMworld)
• vCloud Director
• vCloud Networking and Security (vCNS)

Технология VMware vDGA для VMware Horizon View 5.5

О технологии NVIDIA VGX мы уже писали вот тут, тут и тут. Согласно этой презентации, уже скоро мы увидим возможности шаринга и выделение GPU отдельным виртуальным машинам:

Ну что знал - рассказал. В целом, ничего революционного. Поддержку Fault Tolerance для 4-х vCPU обещают в VMware vSphere 6.0.

Виктору спасибо за ссылки. Вот еще немного о предстоящем выходе обновленной платформы - http://vmind.ru/2013/08/13/vmware-vsphere-5-5/.

Не так давно мы писали о средстве для анализа логов VMware vSphere - VMware vCenter Log Insight, которое было выпущено совсем недавно (пока еще в бета-версии). Продукт поставляется в виде виртуального модуля (Virtual Appliance), который развертывается как обычный OVF-пакет, после чего становится доступен сбор и анализ данных syslog с серверов VMware ESXi 4.1, 5.0, 5.1, а также vCenter Server Appliance и других источников. Кроме того, Log Insight может быть интегрирован с vCenter Operations Manager.

Благодаря усилиям партнеров VMware, а именно CISCO, EMC, HyTrust, NetApp, NetFlow Logic, Puppet Labs и VCE, стали доступны Partner Content Packs для VMware vCenter Log Insight.

Концепция контент-пака такова: вы загружаете Content Pack в Log Insight, после чего вы получаете набор дэшбордов, сохраненных запросов, алертов и описаний различных полей для анализа файлов журналов. По умолчанию вместе с Log Insight идет vSphere Content Pack, который избавит от необходимости знать тонкости debug-сообщений и различные параметры вывода логов серверов VMware ESXi. Все станет проще и понятней.

Следующие пакеты доступны на ресурсе Solution Exchange:

• EMC VMAX Content Pack
• HyTrust Appliance Content Pack for Log Insight
• NetApp Data ONTAP Content Pack for VMware vCenter Log Insight
• Cisco UCS Content Pack for Log Insight
• NetFlow Logic Content Pack for Log Insight
• VCE Vision Intelligent Operations Content Pack for Log Insight
• VMware Nicira NVP Content Pack for Log Insight
• VMware Horizon View Content Pack For Log Insight

Более подробная информация о продукте VMware vCenter Log Insight доступна на специальном портале.

Несомненно, список этих контент-паков будет расти, что вполне может сделать vCenter Log Isight основным средством анализа логов в ИТ-инфраструктуре предприятий.

Компания Veeam Software на днях выпустила новую версию самого лучшего в мире средства для резервного копирования виртуальных машин - Veeam Backup and Replication 7. В седьмой версии появилось не просто много новых возможностей, а очень много - всего продукт насчитывает более 50 нововведений и улучшений. Мы уже писали о новых возможностях Veeam B&R 7, а в этом посте сведем все воедино и приведем сравнение изданий.

Как знают администраторы виртуальных сред и некоторые разработчики, на многих платформах виртуализации существует возможность запуска виртуальных машин в виртуальных машинах с установленным в них гипервизором - так называемая "вложенная виртуализация" (Nested Virtualization). Например, такие возможности есть в VMware vSphere (что позволяет запускать не только свой вложенный гипервизор ESXi, но машины на вложенном гипервизоре Hyper-V).

Компания Ravello нашла интересный способ использовать вложенную виртуализацию в своем продукте Cloud Application Hypervisor, который позволяет универсализовать развертывание ВМ разных платформ виртуализации в публичных облаках различных сервис провайдеров.

Основным компонентом этой системы является технология HVX - собственный гипервизор (на базе Xen), являющийся частью ОС Linux и запускающий вложенные виртуальные машины без их изменения средствами техник бинарной трансляции. Далее эти машины можно разместить в облаках Amazon EC2, HP Cloud, Rackspace и даже частных облаках, управляемых VMware vCloud Director (поддержка последнего ожидается в скором времени).

Продукт Ravello - это SaaS-сервис, а такие матрешки можно просто загружать на любой из поддерживаемых хостингов, вне зависимости от используемого им гипервизора. Виртуальная сеть между машинами создается через L2-оверлей над существующей L3-инфраструктурой хостера с использованием GRE-подобного протокола (только на базе UDP):

Сама механика предлагаемого сервиса Cloud Application Hypervisor такова:

• Пользователь загружает виртуальные машины в облако (поддерживаются машины, созданные на платформах ESXi/KVM/Xen).
• С помощью специального GUI или средствами API описывает многомашинные приложения.
• Публикует свои ВМ в одном или нескольких поддерживаемых облаках.
• Получившаяся конфигурация сохраняется в виде снапшота в облаке Ravello (потом в случае чего ее можно восстановить или выгрузить) - это хранилище может быть создано как на базе облачных хранилищ Amazon S3, CloudFiles, так и на базе собственных блочных хранилищ или NFS-томов.
• После этого каждый пользователь может получить многомашинную конфигурацию своего приложения по требованию.

Очевидный вопрос, который возникает первым: что с производительностью? Ну, во-первых, решение Cloud Application Hypervisor рассчитано на команды разработки и тестирования, для которых производительность не является критичным фактором.

А во-вторых, результаты тестов производительности таких вложенных матрешек показывают не такие уж и плохие результаты:

Для тех, кто заинтересовался технологией HVX, есть хорошее обзорное видео на рунглише:

Больше подробностей о продукте Cloud Application Hypervisor и технологии HVX можно узнать из этого документа.

Как вы знаете, в августе нас ждет главное событие года в сфере виртуализации - конференция VMware VMworld 2013, где будет сделано пара интересных анонсов и будут выпущены новые продукты компании VMware. Уже сейчас стало известно несколько важных моментов, касающихся повышения цен и комплектации продуктов.

Итак, что будет происходить в сентябре этого года:

• С 19 сентября 2013 произойдет повышение цен на следующие продукты:

- vCenter Operations 5.6 Management Suite Advanced
- vCenter Operations 5.6 Management Suite Enterprise 

• С 19  сентября 2013 прекращаются продажи лицензий vCloud Director - теперь он будет продаваться только в составе комплекта vCloud Suite 
• С 30 сентября 2013 прекращаются продажи лицензий vCloud Networking and Security - теперь он будет продаваться только в составе комплекта vCloud Suite 

• С 19 сентября 2013 изменятся партномера, а также повысятся цены на лицензии, апгрейды и техподдержку для пакета VMware vSphere 5 Essentials Plus Kit for 3hosts.

Будет два варианта комплектации Essentials Plus Kit:

- VMware vSphere 5 Essentials Plus Kit for 3 hosts  - стандартный набор из лицензий на три 2-процессорных хоста ESXi, но теперь без vSphere Storage Appliance (VSA) в своем составе.
- VMware vSphere 5 Essentials Plus Kit with VSA - это vSphere 5 Essentials Plus Kit с включенным в состав компонентом vSphere Storage Appliance.

И да - для них станет доступна скидка по программе VPP.

• С 19 сентября 2013 изменятся партномера у лицензий, апгрейдов и техподдержки на продукты семейства VMware vSphere with Operations Management. Цены останутся прежними.

Это коснется следующих продуктов:

- VMware vSphere with Operations Management Standard for 1 processor
- VMware vSphere with Operations Management Enterprise for 1 processor
- VMware vSphere with Operations Management Enterprise Plus for 1 processor

Большинству администраторов VMware vSphere известно, что у виртуальной машины могут быть виртуальные сетевые адаптеры различных типов, которые выбираются как в зависимости от гостевой ОС, так и от настроек пользователя, которые можно прописать в vmx-файле конфигурации ВМ.

На эту тему компания VMware выпустила вот такое видео:

Опишем типы сетевых адаптеров (vNIC) для виртуальной машины (ранее мы писали о них тут):

• Vlance - этот адаптер эмулирует реально существующий старый адаптер AMD 79C970 PCnet32- LANCE NIC, он работает на скорости 10 Mbps, и для него есть драйверы в большинстве 32-битных ОС, за исключением Windows Vista и более поздних версий. Виртуальная машина с таким адаптером может сразу использовать сеть.
• VMXNET - такой адаптер уже не имеет физического воплощения, то есть он полностью виртуальный. Он оптимизирован с точки зрения производительности ВМ. Поскольку он виртуальный - ОС не может его использовать, пока не установлены драйверы, идущие в комплекте с VMware Tools.
  
• Flexible - это по-сути не адаптер, а способ его представления. Он ведет себя как Vlance при загрузке ВМ, но потом превращается (или нет - в зависимости от VMware Tools) в VMXNET.
• E1000 - это эмулируемая сетевая карта Intel 82545EM Gigabit Ethernet NIC. Драйвер для этого адаптера есть не во всех гостевых операционных системах. Обычно Linux с версиями ядра 2.4.19 или более поздними, Windows XP Professional x64 Edition и позднее, а также Windows Server 2003 (32-bit) и позднее включают в себя драйвер для этого устройства. Производительность его достаточно неплоха. Драйвер адаптера E1000 не поддерживает большие кадры jumbo frames до версии VMware ESXi/ESX 4.1.
• E1000e - этот адаптер эмулирует более продвинутую модель Intel Gigabit NIC (number 82574) в виртуальном аппаратном обеспечении (virtual hardware) виртуальной машины. Адаптер e1000e доступен только для virtual hardware версии 8 (и старше), начиная с VMware vSphere 5. Это дефолтный адаптер для Windows 8 и более новых гостевых ОС. Для гостевых ОС Linux e1000e не доступен для выбора из интерфейса (e1000, flexible, vmxnet, enhanced vmxnet и vmxnet3 - доступны для Linux).
• VMXNET 2 (Enhanced) - адаптер VMXNET 2 основан на устройстве VMXNET, но предоставляет несколько функций с улучшенной производительностью, таких как jumbo frames и hardware offloads (например, TCP Segmentation Offloading, TSO). Этот адаптер доступен только для хостов VMware ESX/ESXi 3.5 или выше. Устройство VMXNET 2 поддерживается только для следующих гостевых операционных систем:
  • 32- и 64-битные версии Microsoft Windows 2003 (Enterprise и Datacenter Edition). Можно использовать адаптер VMXNET 2 и на Microsoft Windows 2003, однако нужно прочитать статью в KB 1007195 (http://kb.vmware.com/kb/1007195  ).
  • 32-битная версия Microsoft Windows XP Professional
  • 32- и 64-битные версии Red Hat Enterprise Linux 5.0
  • 32- и 64-битные версии SUSE Linux Enterprise Server 10
  • 64-битные версии Red Hat Enterprise Linux 4.0
  • 64-битные версии Ubuntu Linux
  
  Кроме того, если такой адаптер недоступен для выбора в Windows 2003, то нужно почитать статью Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195).
  
  В ESX 3.5 Update 4 или более поздних версиях платформы следующие гостевые ОС также поддерживаются для этого адаптера:
  
  
  • Microsoft Windows Server 2003, Standard Edition (32-bit)
  • Microsoft Windows Server 2003, Standard Edition (64-bit)
  • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003
  
  Jumbo frames также не поддерживаются для гостевых ОС Solaris с адаптером VMXNET 2.
  
  
• VMXNET 3 - это следующее поколение виртуальных сетевых карт, которое теперь паравиртуализовано. То есть часть того, что раньше полностью эмулиировалось, теперь передается напрямую в физическое устройство. Этот адаптер не является надстройкой над VMXNET или VMXNET 2, но включает в себя все доступные для них возможности. Например, к ним относятся: поддержка механизмов нескольких очередей (multiqueue - также известны как Receive Side Scaling в Windows), IPv6 offloads, а также прерывания MSI/MSI-X (подробнее - тут).
  VMXNET 3 поддерживается только для виртуальных машин с виртуальным аппаратным обеспечением уровня 7 или более поздним, при этом только для следующих гостевых систем:
  • 32- и 64-битные версии Microsoft Windows XP и более поздние (включая Windows 7, 2003, 2003 R2, 2008, 2008 R2 и Server 2012)
  • 32- и 64-битные версии Red Hat Enterprise Linux 5.0 и более поздние
  • 32- и 64-битные версии SUSE Linux Enterprise Server 10 и более поздние
  • 32- и 64-битные версии Asianux 3 и более поздние
  • 32- и 64-битные версии Debian 4/Ubuntu и более поздние
  • 32- и 64-битные версии Sun Solaris 10 U4 и более поздние
  
  Заметки:
  
  • В ESXi/ESX 4.1 и более ранних версиях jumbo frames не поддерживаются для гостевых ОС Solaris для адаптеров VMXNET 2 и VMXNET 3. Эта возможность поддерживается, начиная с ESXi 5.0 только для адаптеров VMXNET 3. Более подробно можно почитать в статье Enabling Jumbo Frames on the Solaris guest operating system (2012445).
    
  • Технология Fault Tolerance не поддерживается для ВМ с адаптером VMXNET 3 в vSphere 4.0, но поддерживается в vSphere 4.1 и более поздних версиях.
  • Windows Server 2012 поддерживается для адаптеров e1000, e1000e и VMXNET 3 на платформе ESXi 5.0 Update 1 и более поздни

О производительности устройства VMXNET3 можно почитать в документе "Performance Evaluation of VMXNET3 Virtual Network Device".

Для того, чтобы использовать тот или иной тип виртуального сетевого адаптера для виртуальной машины, необходимо выставить его при добавлении к виртуальной машине при создании или редактировании свойств.

Также vNIC можно добавить с помощью добавления строчек в конфигурационный vmx-файл виртуальной машины:

• Для адаптера типа Flexible ничего добавлять не требуется.
• Ethernet[X].virtualDev = "e1000" - для добавления сетевого адаптера E1000.
• Ethernet[X].virtualDev = "vmxnet" - для добавления адаптера VMXNET 2 (Enhanced).
• Ethernet[X].virtualDev = "vmxnet3" - для добавления адаптера VMXNET3.

Вместо [X] необходимо подставить номер виртуального сетевого адаптера, начиная с 0.

Кстати, забыл тут про одну вещь. Не все администраторы VMware vSphere знают, что для того, чтобы зайти в черно-серое меню сервера VMware ESXi вовсе не обязательно использовать доступ через встроенную консоль типа HP iLO. Имеется в виду вот это меню настройки сервера (аналогично DCUI - Direct Console User Interface):

Все можно сделать прямо из SSH-сессии, если вы работаете под пользователем, имеющим локальную роль Administrator. Нужно просто выполнить команду:

# dcui

И вуаля - можно настраивать сервер без всяких iLO:

Само собой, это не работает в Lockdown mode, так как оно запрещает использование всех внешних интерфейсов, за исключением VMware vCenter Server (однако непосредственно в физическую консоль администратору залогиниться в этом режиме, конечно, можно).

Иногда, вследствие ошибки или отсутствия поддержки каких-либо функций, появляется необходимость обновить драйвер HBA-адаптера на сервере VMware ESXi - ведь ждать очередного обновления vSphere с обновленными драйверами можно очень долго.

Поэтому можно обновиться самим - это просто. Смотрим на свои адаптеры HBA, для чего выполняем команду:

# esxcfg-scsidevs -a

Здесь мы видим в каких слотах сервера размещены адаптеры (и производителя адаптера), но не видим версий их Firmware. Поэтому смотрим в девайсы, например для адаптера Qlogic (как смотреть остальные - тут):

# more /proc/scsi/qla2xxx/0

Здесь мы видим версию Firmware - 5.03.15 и метку версии драйвера.

Далее нужно посмотреть в KB 2030818 (Supported Driver Firmware versions for I/O devices) для того, чтобы определить поддерживаемые для ESXi драйверы адаптеров и рекомендации по текущей версии.

Например, для серверов HP идем в http://vibsdepot.hp.com/hpq/recipes/, где находим документ "HP-VMware-Recipe.pdf", в котором есть ссылки на необходимые драйверы:

Скачиваем нужный драйвер, например:

qla2xxx-934.5.6.0-887798.zip

Распаковываем архив и находим там .vib-файл:

scsi-qla2xxx-934.5.6.0-1OEM.500.0.0.472560.x86_64.vib

Теперь этот файл надо положить в папку:

/var/log/vmware

И запустить команду:

# esxcli software vib update -v scsi-qla2xxx-934.5.6.0-1OEM.500.0.0.472560.x86_64.vib

Перезагружаем сервер для применения изменений и убеждаемся, что драйвер накатился с помощью команды:

# more /proc/scsi/qla2xxx/0

Детальную информацию о VIB-пакете можно получить с помощью команд:

# esxcli software vib list | grep scsi
# esxcli software vib get -n scsi-qla2xxx

У некоторых виртуальных машин на платформе VMware vSphere может оказаться такая ситуация, что на одном виртуальном диске VMDK окажутся 2 логических раздела - например, диски C и D в Windows. Произойти это может вследствие P2V-миграции физического сервера в ВМ или изначальной конфигурации машины.

При этом, для каких-то целей вам может потребоваться эти логические диски разнести по двум файлам VMDK (например, для целей хранения дисков на разных "ярусах" хранения). Решить эту проблему весьма просто с помощью VMware vCenter Converter (мы писали о нем тут).

Делается так это все так:

• Начинаем процесс конвертации виртуальной машины
• Идем в мастере конверсии в Options
• Для раздела "Data to copy" выбираем "Edit"
• Выбираем опцию "Data copy type" и меняем ее на "Select volumes to copy".
• Далее на вкладке "Target Layout" в представлении "Advanced" настраиваем разнесение логических дисков по разным vmdk, как на картинке ниже.

Источник.

Как многие из вас знают, мы своевременно обновляем посты про диаграммы портов и соединений различных компонентов VMware vSphere и других продуктов компании. Об этом можно почитать, например, тут, тут и тут.

Недавно вышло очередное обновление схемы портов VMware vSphere 5.1. Схема уже является официальной и приведена в KB 2054806.

Приятно также и то, что теперь в этом же документе в виде таблицы приведены все порты различных компонентов VMware vSphere 5.x и назначение соединений:

Мы много пишем о проекте VMware Labs, созданный для того, чтобы инженеры VMware выкладывали там свои наработки, которые не были оформлены в виде конечных продуктов компании (заметки об этом можно найти у нас по тэгу Labs).

На этот раз на VMware Labs появилась по-настоящему полезная штука - VisualEsxtop. Как можно догадаться из названия, эта утилита, написанная на Java, позволяет визуализовать данные о производительности в реальном времени, выводимые командой esxtop. Утилита кроссплатформенная и работает под Windows и Linux как .bat или .sh сценарий.

Возможности VisualEsxtop:

1. Соединение как с отдельным хостом ESXi, так и с vCenter Server.
2. Гибкий способ пакетного вывода результатов.
3. Загрузка результатов пакетного вывода и его "прогонка" (replay).
4. Возможность открыть несколько окон для отображения различных данных одновременно.
5. Визуализация в виде графика выбранных счетчиков производительности.
6. Гибкий выбор и фильтрация счетчиков.
7. Тултип на ячейках счетчиков, объясняющий их назначение (см. картинку).
8. Цветовое кодирование важных счетчиков.

Также VisualEsxtop можно заставить работать под Mac OS X - для этого почитайте вот эту статью.

Скачать VisualEsxtop можно по этой ссылке. Четырехстрочная инструкция доступна тут.

Новость, конечно, не свежая, поскольку о выходе Windows Server 2012 R2 Tech Preview стало известно еще на прошлой неделе, однако она заслуживает внимания. Напомним, что мы уже писали о новых возможностях платформы виртуализации Hyper-V в Windows Server 2012 R2, которая теперь полностью синхронизирована по версиям со средством управления Virtual Machine Manager. Новый Hyper-V имеет больше возможностей для масштабирования виртуальной инфраструктуры, а также существенно лучше стали работать средства автоматизации и сервисы динамической инфраструктуры, такие как Live migration, Storage QoS и Storage tiering.

Итак, ссылки на загрузку Windows Server 2012 R2:

• Windows Server 2012 R2 Preview for IT Professionals
• Windows Server 2012 R2 Preview on Windows Azure
• Windows Server 2012 R2 Preview for Developers
• Windows Server 2012 R2 Essentials Preview

Установка Windows Server 2012 R2 в виртуальной машине на VMware ESXi:

Также был выпущен новый System Center 2012 R2, из которого вам понадобится как минимум Virtual Machine Manager для управления инфраструктурой виртуализации:

• System Center 2012 R2 Preview Datacenter/Private Cloud
• System Center 2012 R2 Configuration Manager & Endpoint Protection Preview

Кроме того, стал доступен для загрузки Windows Azure Pack - решение для сервис-провайдеров и крупных датацентров, которое позволяет создать единый портал управления гибридным облаком Microsoft, включающий в себя собственные мощности предприятия и сервисы публичного облака Azure. Более подробно о Windows Azure Pack можно узнать из этого документа.

Скачать Windows Azure Pack можно по этой ссылке.

Ну и для тех, кому актуально, обновился SQL Server - теперь доступно его превью 14-го года:

• SQL Server 2014 Community Technology Preview 1
• SQL Server 2014 Community Technology Preview 1 on Windows Azure

Мы часто пишем заметки о безопасности виртуальной инфраструктуры VMware vSphere и других продуктов на данной платформе (их можно найти по тэгу Security). И вот на днях я натолкнулся на интересную статью "It’s a Unix system, I know this!", в которой есть одна умная мысль, касающаяся настройки безопасности, и которую я часто пытаюсь донести до заказчиков. А именно: некорректное планирование и исполнение процедур по обеспечению безопасности может привести к еще большим проблемам как с точки зрения конфигурации виртуальной среды, так и с точки зрения самой безопасности.

Итак, обратимся к статье. Есть такая организация в штатах Defense Information Systems Agency (DISA), которая выпускает документ Security Technical Implementation Guide (STIG), являющийся руководящим документом по обеспечению безопасности для правительственных организаций. Есть подозрение, что в части виртуальных машин он сделан на основе VMware vSphere Security Hardening, однако не из самой актуальной версии последнего.

Так вот в этом DISA STIG есть пункты, касающиеся виртуальных машин, например, пункт про отключение операций Copy/Paste с гостевой ОС виртуальной машины из ОС компьютера, где выполняется vSphere Client.

Посмотрим, как рекомендуется выполнить эту процедуру:

To edit a powered-down virtual machine’s .vmx file, first remove it from vCenter Server’s inventory. Manual additions to the .vmx file from ESXi will be overwritten by any registered entries stored in the vCenter Server database. Make a backup copy of the .vmx file. If the edit breaks the virtual machine, it can be rolled back to the original version of the file.

1. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Storage. Right-click on the appropriate datastore and click Browse Datastore. Navigate to the folder named after the virtual machine, and locate the <virtual machine>.vmx file. Right-click the .vmx file and click Remove from inventory.

2. Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client.

3. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required.

4. As root, log in to the ESXi host and locate the VM’s vmx file.

# find / | grep vmx

Add the following to the VM’s vmx file.
keyword = “keyval”

Where:
keyword = isolation.tools.copy.disable
keyval = TRUE

5. Re-enable Lockdown Mode on the host.

6. Re-register the VM with the vCenter Server:

Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials.
If connecting to vCenter Server, click on the desired host.
Click the Configuration tab.
Click Storage.
Right-click on the appropriate datastore and click Browse Datastore.
Navigate to the folder named after the virtual machine, and locate the <virtual machine>.vmx file.
Right-click the .vmx file and click Add to inventory. The Add to Inventory wizard opens.
Continue to follow the wizard to add the virtual machine.

Круто, да? Это все для того, чтобы просто отключить копирование из консоли ВМ (для одной машины), которое если уж кому-то очень сильно понадобится - он сделает все равно через принтскрин или еще как.

А теперь подумаем, к чему это все может привести:

• В процессе такой настройки администратор может что-то испортить.
• Сотни виртуальных машин обработать таким способом очень долго и нудно.
• Такая процедура открывает больше дырок, чем закрывает (администратор снимает Lockdown хоста, делает операции в шеле и тыркается по вицентру).
• Контролировать исполнение процесса очень сложно - все ли локдауны были закрыты, по всем машинам ли мы прошлись и т.п.

Конечно же, есть простой и элегантный способ сделать все это сразу для всех ВМ и с помощью PowerCLI через методы, описанные в пунктах vm.disable-console-copy и vm.disable-console-paste документа vSphere Hardening Guide.

Однако те из вас, у кого в компании есть отдел информационной безопасности, знают что такое формализм этих ребят, которые может в виртуализации и не разбираются, зато прекрасно понимают, что приведенный выше гайд несколько отличается от двух строчек на PowerShell.

И, хотя это в основном касается западных организаций, в отечественных крупных компаниях тоже возникают проблемы из-за подобных процедур.

Так вот какова мораль сей басни:

• При разработке руководящих документов по обеспечению безопасности виртуальной инфраструктуры поймите, какие требования являются обязательными, а какие можно реализовать факультативно (то есть не реализовывать вовсе). Минимизируйте число обязательных требований и по мере необходимости расширяйте.
• Используйте последние версии руководящих документов по ИБ от вендоров и всегда обновляйте свои собственные (хотя бы с выходом мажорной версии продукта).
• Максимально применяйте автоматизацию при выполнении процедур по конфигурации безопасности. В VMware vSphere и других продуктах VMware можно автоматизировать практически все.
• Если выполнение требования к ИБ виртуальной среды потенциально может открыть еще больше дырок, вызвать ошибки конфигурации и причинить еще беды, подумайте - а может стоит отказаться от этого требования или переформулировать его?

Ну а если кратко - с головой надо подходить, а формализм отставить. Больше интересных подробностей - в статье.

Продолжаем знакомить вас с багами VMware vSphere 5.1 - ведущей платформы виртуализации. На этот раз мы расскажем о баге VMware vSphere Client, для чего откроем вкладку редактирования пользователя и посмотрим на его свойства:

Такую картину мы увидим в том числе и тогда, когда пользователь VMware ESXi был создан автоматически, например, при использовании функций AutoDeploy и Host Profiles. Не очень понятно, почему это пользователю при создании по дефолту гарантируются права на доступ к консоли ESXi, а вот в списке групп, где он состоит, наблюдается пустота.

Все на самом деле просто: в vSphere 5.1 поменялся подход к безопасности, а вот сделать обновление vSphere Client забыли, так как сейчас идет переход на vSphere Web Client, и никому нет дела до толстого клиента. Соответственно, аспекты этого бага таковы:

• Галка "Grant shell access to this user" ни на что не влияет. Важно только, назначена ли роль Administrator пользователю (что позволит ему войти в консоль сервера).
• Поле Group пустое, так как ESXi больше не использует информацию из /etc/groups, а использует свою модель пользователей и групп:

• Поэтому вновь создаваемый пользователь с галкой "Grant shell access to this user" не сможет соединиться по SSH и зайти в консоль, то есть это баг UI:

Иногда возникает потребность правильно выключить виртуальные машины VMware vSphere в определенной последовательности, чтобы не нарушить консистентность данных и приложений. Требуется это при различных сценариях обслуживания инфраструктуры, переездах оборудования, подготовке к отключениям электричества и т.п. Ну а потом, соответственно, эти ВМ нужно включить - и тоже в нужной последовательности.

Специально для таких случаев Graham French допилил скрипт на PowerShell / PowerCLI, который автоматизирует процессы Startup / Shutdown для виртуальных машин на ESXi. Грэхам подошел к задаче научно - он разделил все ВМ на 5 слоев, отражающих очередность выключения машин:

• Phase 1 - веб-серверы, балансировщики нагрузки, принт-серверы - то есть некритичные машины и машины на краю периметра датацентра.
• Phase 2 - серверы приложений и другие серверы, являющиеся фронтэнд-звеном в архитектуре многокомпонентных приложений.
• Phase 3 - серверы баз данных и кластеризованные серверы.
• Phase 4 - NAS-серверы и файловые серверы.
• Phase 5 - сервисы обеспечения инфраструктуры: Active Directory, DNS, DHCP, виртуальные модули (Virtual Appliances).

Соответственно, правильной схемой выключения виртуальных машин является последовательность Phase 1 -> Phase 5. Скрипт принимает на вход имена виртуальных машин в CSV-файлах, а также умеет выключать/включать и физические серверы:

Для включения машин используем обратную последовательность Phase 5 -> Phase 1:

Сам скрипт Startup / Shutdown и примеры CSV-файлов можно скачать по этой ссылке.

Недавно Duncan Epping опубликовал интересную статью о параметре Mem.MinFreePct, который есть в настройках сервера VMware ESXi из состава vSphere. По-сути, этот параметр определяет, какое количество оперативной памяти VMkernel должен держать свободным на хосте, чтобы всегда были доступные ресурсы под нужды системы, и хост не вывалился в PSOD.

В VMware vSphere 4.1 параметр Mem.MinFreePct составлял 6% и его можно было изменять с помощью следующей команды:

vsish -e set /sched/freeMemoryState/minFreePct <Percentage>

Например, вот так можно было установить Mem.MinFreePct в значение 2%:

vsish -e set /sched/freeMemoryState/minFreePct 2

Этак команда, кстати, не требует перезагрузки, но зато после перезагрузки значение Mem.MinFreePct не сохраняется. Поэтому данную команду, если требуется, нужно занести в /etc/rc.local (подробнее в KB 1033687).

Параметр этот очень важный, поскольку от него зависят пороги использования различных механизмов оптимизации памяти хоста ESXi. При этом, если памяти на хосте много (например, десятки гигабайт), то держать постоянно 6% свободной памяти может быть для кого-то расточительством. Поэтому, начиная с VMware vSphere 5.0, параметр Mem.MinFreePct является "плавающим" и устанавливается в зависимости от объема физической памяти на хосте ESXi.

Вот какие значения принимает Mem.MinFreePct в зависимости от того, сколько RAM есть на вашем физическом хост-сервере:

А вот какие механизмы оптимизации памяти на хосте работают, если свободной памяти становится все меньше и меньше:

Интересно, конечно, но как-то бесполезно. Зачем загонять хост в такие лимиты? Лучше как минимум процентов 10 всегда держать свободными и своевременно покупать новые серверы.

Компания VMware опубликовала очередной номер своего технического журнала VMware Technical Journal Summer 2013, в котором разбираются наиболее интересные технические аспекты решений для виртуализации на весьма глубоком уровне (зачастую даже с математическими выкладками). Напомним, что о предыдущем выпуске VMware Technical Journal мы писали вот тут. Как и в прошлом выпуске все статьи доступны онлайн и как PDF (5 МБ).

Темы нового номера:

• Introduction
• Memory Overcommitment in the ESX Server
• Redefining ESXi IO Multipathing in the Flash Era
• Methodology for Performance Analysis of VMware vSphere under Tier-1 Applications
• vATM: VMware vSphere Adaptive Task Management
• An Anomaly Event Correlation Engine: Identifying Root Causes, Bottlenecks, and Black Swans in IT Environments
• Simplifying Virtualization Management with Graph Databases
• Autonomous Resource Sharing for Multi-Threaded Workloads in Virtualized Servers

Мне понравились "Redefining ESXi IO Multipathing in the Flash Era" и "Methodology for Performance Analysis of VMware vSphere under Tier-1 Applications".

На днях компания VMware объявила о начале публичного бета-тестирования своего нового средства для анализа логов VMware vSphere - VMware vCenter Log Insight 1.0. Продукт поставляется в виде виртуального модуля (Virtual Appliance), который развертывается как обычный OVF-пакет, после чего становится доступен сбор и анализ данных syslog с серверов VMware ESXi 4.1, 5.0, 5.1, а также vCenter Server Appliance и других источников. Кроме того, Log Insight может быть интегрирован с vCenter Operations Manager.

Возможности VMware vCenter Log Insight 1.0:

• High Performance Ingestion - Log Insight принимает данные от syslog или через API на скорости до 1000 Мбит/с на один виртуальный модуль
• Near Real-Time Search - входящие данные доступны для поиска почти сразу и могут быть агрегированы с историческими данными в одном большом логе.
• Aggregation - данные группируются методом похожим на GROUP-BY в реляционных БД.
• Runtime Field Extraction - Log Insight может доставать данные из сырого лога средствами регулярных выражений.
• Dashboards - администраторы могут создавать свои дэшборды из запросов к базе логов.
• Scalability - инфраструктуру Log Insight можно наращивать за счет добавления дополнительных серверов.

Полезная документация по продукту:

• VMware vCenter Log Insight 1.0 Beta Getting Started Guide
• VMware vCenter Log Insight 1.0 Beta Virtual Appliance Sizing
• Log Insight 1.0 Beta Installation and Administration Guide
• Log Insight 1.0 Beta User's Guide

Скачать бета-версию VMware vCenter Log Insight 1.0 можно по этой ссылке.

Когда-то давно мы публиковали заметки о P2V-миграции физических серверов в виртуальные машины на платформе тогда еще VMware ESX Server (а также рассказывали о необходимых действиях после миграции). С тех пор многое изменилось, вышел VMware vCenter Converter Standalone 5.0, процесс миграции стал проще и стабильнее, а также накопилось пару моментов, о которых можно рассказать. Кроме того, появилась отличная статья на эту тему. Итак, есть 3 типа P2V-миграции...

Некоторые из вас, возможно, в курсе, что существует такой проект Google Authenticator, который позволяет организовать двухфакторную аутентификацию через телефон (как по СМС, так и через приложение), которая позволяет не только вводить свой постоянный пароль, но и дополнительно временно генерируемый код, что существенно снижает риски несанкционированного доступа. Возможно, кто-то из вас использует это для своей почты на GMAIL:

Данный способ аутентификации очень надежен, так как злоумышленник без вашего телефона не получит доступа к сервису, поскольку он не получит временный пароль, а украв ваш телефон, он тоже не получит доступа, так как не знает постоянного пароля. Однако и этот способ не защищает от древнейшей утилиты взлома шифров и паролей - раскаленного утюга.

Компания VMware несколько доработала этот продукт, и на сайте проекта VMware Labs появился новый флинг - ESXi Google Authenticator, который позволяет организовать двухфакторную аутентификацию для доступа к консоли хост-серверов по SSH.

Для данного механизма обеспечения дополнительной безопасности поддерживаются хост-серверы ESXi 5.0 и 5.1, при этом допускается несколько администраторов одного сервера, использующих Google Authenticator (только ESXi 5.1).

Основные возможности ESXi Google Authenticator:

• Поддержка двухфакторной аутентификации как для ESXi Shell, так и для доступа через SSH.
• Поддержка нескольких логинов для ESXi 5.1 и одного (root) для ESXi 5.0.
• Поддержка 30-секундных кодов TOTP (меняются каждые полминуты).
• Поддержка кодов аварийного логина на случай, если телефон был украден (emergency scratch codes).
• Защита от атак с повторением запросов.

Технически аутентификация в ESXi Google Authenticator организована средствами модуля PAM (Pluggable Authentication Module) и специального приложения, доступного для платформ Android, iOS и Blackberry.

Устанавливается приложение одной командой:

esxcli software vib install -v --no-sig-check -f /path/to/the/vib

Далее нужно читать инструкции по использованию тут, а также в целом рекомендуется ознакомиться с проектом Google Authenticator.

Многие знают, что VMware vSphere версий 5.0 (начиная с Update 1) и 5.1 в полном объеме поддерживают Windows Server 2012 и Windows 8 в гостевых ОС виртуальных машин. Однако, еще далеко не во всех компаниях установлены последние версии гипервизора VMware ESXi - особенно в крупных организациях еще много где используют версию ESX/ESXi 4.x.

При попытке установить Windows Server 2012 и Windows 8 в виртуальной машине ESX/ESXi 4.x, выбрав в качестве гостевой ОС Microsoft Windows Server 2008 R2, администратор получит вот такую ошибку:

Your PC ran into a problem that it couldn't handle, and now it needs to restart

You can search for the error online: HAL_INITIALIZATION_FAILED

Решить эту проблему очень просто:

• Создаем новую ВМ в vSphere Client.
• В качестве типа гостевой ОС (Guest Operating System) выбираем Microsoft Windows Server 2008 R2 (64-bit).
• Скачиваем вот этот файл bios и кладем его в папку с виртуальной машиной

Далее в конфигурационный файл .vmx в папке с ВМ добавляем следующие строчки:

bios440.filename = "bios.440.rom"
mce.enable = TRUE
cpuid.hypervisor.v0 = FALSE
vmGenCounter.enable = FALSE

Теперь можно устанавливать и использовать Windows 8 и Windows Server 2012 в виртуальной машине на VMware ESXi 4.1.

Второй этап - это установка свежих VMware Tools в таких виртуальных машинах. Об этом мы писали в статье "Как обновить VMware Tools старых хост-серверов, не обновляя хостов VMware vSphere / ESXi".

Не так давно мы писали про средства управления питанием хост-серверов ESXi, которые имеются в VMware vSphere 5.1. Там мы рассматривали такую политику как Balanced - она разработана для того, чтобы максимально использовать переключения между состояниями P-states процессора в целях экономии энергии. Она обладает слегка большей инерционностью, чем обычное максимальное использование ресурсов процессора (High performance), но почти не влияет на производительность. Эта политика выставлена по умолчанию для серверов VMware ESXi 5.0 и более поздней версии.

Недавно на блоге VROOM! компании VMware появилось интересное исследование, посвященное механизмам управления питанием серверов ESXi. Как и обычно, в качестве инструмента для тестирования и создания нагрузки на хосты ESXi использовался продукт VMware VMmark, который и был разработан для тестирования производительности решений VMware на различных аппаратных платформах.

Сравнивались три подхода к управлению питанием:

• Политика Performance - максимальное использование процессора за счет его поддержки в наивысшем P-state состоянии все время (то есть, по-сути политика энергосбережения отключена). При этом используются только 2 C-state состояния: С0 (running) и C1 (halted). Соответственно, данный режим выдает максимальную производительность, не имеет инерционности и потребляет больше всего энергии. Управляется эта политика BIOS'ом сервера.
• Политика Balanced - сбалансированное энергопотребление за счет переключения между P-states. Эта политика управляется хостом ESXi.
• Политика BIOS Balanced - функции энергосбережения, которые управляются на уровне BIOS сервера (например, Dell Active Power Controller).

Для тестирования производительности использовался стандартный подход VMmark, который предполагает создание возрастающих уровней нагрузки на хост-серверы (Tiles).

С точки зрения аппаратной платформы, использовалась следующая конфигурация:

• 4 сервера Dell PowerEdge R620
• CPUs (на сервер): один Eight-Core Intel® Xeon® E5-2665 @ 2.4 GHz, Hyper-Threading enabled
• Memory (на сервер): 96GB DDR3 ECC @ 1067 MHz
• Host Bus Adapter: два QLogic QLE2562, Dual Port 8Gb Fibre Channel to PCI Express
• Network Controller: один Intel Gigabit Quad Port I350 Adapter
• Версия гипервизора: VMware ESXi 5.1.0
• Дисковый массив: EMC VNX5700
• 62 флеш-диска (SSDs), RAID 0, сгруппированных в 3 x 8 SSD LUNs, 7 x 5 SSD LUNs и 1 x 3 SSD LUN
• Средства управления: VMware vCenter Server 5.1.0
• Версия VMmark: 2.5
• Power Meters: три устройства Yokogawa WT210

Итак, что получилось. График очков VMmark (чем выше столбики - тем лучше). Результаты нормализованы к BIOS Balanced на уровне Tile 1:

Как мы видим, худшие результаты показывает политика BIOS Balanced.

Теперь посмотрим на результаты тестов по новой методике VMmark 2.5, позволяющей измерять производительность сервера на киловатт питания:

Как мы видим, политика Performance показывает самые низкие результаты (это логично, так как энергии потребляется много, а столько мощности не всегда требуется процессору), политика ESXi Balanced показывает результат на 3% лучше, а вот политика BIOS Balanced - аж на 20% лучше.

Кстати, интересны измерения потребления мощности при простаивающем процессоре:

• Политика Performance потребляет 128 Вт
• ESXi Balanced - 85 Вт
• BIOS Balanced - тоже около 85 Вт

Казалось бы, почему тогда не использовать BIOS Balanced? А вот почему - при тестировании нагрузки приложений политика BIOS Balanced выдает огромные задержки (latency), негативно влияющие на производительность:

Таким образом, если снова вернуться к первому графику с обобщенными результатами, можно понять, что политика ESXi Balanced является наиболее оптимальной с точки зрения энергопотребления/производительности, поэтому-то она и установлена по умолчанию.

Не все администраторы платформы VMware vSphere в курсе, что на сервере VMware vCenter могут быть отключены различные фильтры хранилищ для хостов ESXi, что может оказаться полезным в нестандартных ситуациях.

Эти фильтры могут настраиваться через консоль vCenter в разделе расширенных настроек. Чтобы иметь возможность настраивать фильтры нужно выбрать пункт меню Administration > vCenter Server Settings. Далее в списке настроек нужно выбрать Advanced Settings.

На данный момент актуально четыре фильтра для хранилищ, включенных на хостах ESXi по умолчанию. Они помогают предотвращать ошибки, которые могут привести к повреждению и потере данных в исключительных ситуациях. Однако (зачастую, временно) эти фильтры можно отключить, но делать это нужно обдуманно, при этом не нужно забывать их снова включать.

В таблице ниже представлены назначение фильтров и конфигурация их выключения на сервере vCenter.

Ну и видео для тех, кому удобнее воспринимать из визуального ряда:

Иногда попытка включить фильтр после его временного отключения приводит к ошибке. Тогда нужно на сервере vCenter в файле vpxd.cfg найти и поправить соответствующую строчку в конфигурационном xml-файле:

<filter>
<hostRescanFilter>true</hostRescanFilter>
</filter>

При внесении описанных здесь изменений не обязательно перезапускать сервер vCenter - так как это всего лишь фильтры для мастера добавления хранилищ, они будут применены сразу же. Однако будьте осторожны с изменением фильтров, так как можно потерять данные.

Как знают администраторы решения для виртуализации настольных ПК VMware Horizon View, есть 2 варианта кастомизации Windows-десктопов при их развертывании в рамках пулов - через утилиту QuickPrep компании VMware и с помощью Sysprep от Microsoft.

При этом иногда можно использовать только Sysprep (для полных клонов, Full Clones), а иногда обе утилиты (для связанных клонов, Linked Clones):

Когда же нужно использовать Sysprep, а когда QuickPrep? На это дает ответ KB 2003797. Приведем здесь основные моменты.

Итак, есть сравнительная таблица возможностей утилит для кастомизации ОС:

Как видно из таблицы, утилита QuickPrep обладает значительно меньшим набором возможностей, чем Sysprep, однако имеет такой плюс, что после ее работы перезапускать виртуальный ПК не требуется.

Что именно делает QuickPrep:

• Создает новый аккаунт в AD для каждого виртуального ПК
• Переименовывает десктоп в соответствии с заданными значениями
• Присоединяет компьютер к домену
• Монтирует том с профилем пользователя (если необходимо)

Если требуется что-то сверх этого, то необходимо использовать Sysprep. Начиная с Windows 7, он уже встроен в саму ОС от Microsoft, а если вы используете Windows XP, то придется использовать отдельный пакет Sysprep (его нужно загрузить на сервер VMware vCenter), как описано в KB 1005593 (мы также писали об этом вот тут).

Продолжаем рассказывать о возможностях новой версии универсального решения для резервного копирования и репликации  Veeam Backup and Replication 7. Напомним, что продукт должен выйти в третьем квартале этого года, а пока Veeam анонсировала, что раскроет семь новых возможностей B&R, каждая из которых является существенным улучшением не только по сравнению с предыдущей версией, но и на фоне любых других продуктов для резервного копирования виртуальных машин.

Вот предыдущие наши статьи на эту тему:

• Компания Veeam Software начала рассказывать о новой версии Veeam Backup and Replication 7 (возможность №1)
• Veeam анонсировала еще одну возможность Veeam Backup and Replication 7 - плагин для vSphere Web Client (№2)
• Третья новая возможность Veeam Backup and Replication 7 - восстановление объектов Microsoft SharePoint (№3)
• Компания Veeam Software рассказала о еще одной новой возможности Backup and Replication 7 - поддержка ленточных библиотек (№4 и №5)
• Компания Veeam рассказала о шестой новой возможности Veeam Backup and Replication 7 - улучшенный 1-Click Restore (№6)

На днях компания Veeam рассказала о последнем нововведении - возможности создания виртуальных лабораторий для реплик виртуальных машин, являющихся копиями основных производственных систем.

Источник данной возможности - запросы пользователей на механизм проверки работоспособности резервной инфраструктуры реплик, позволяющий быть уверенным, что в случае сбоя основного сайта, реплики смогут запуститься корректно на резервной площадке, и требования к RTO будут выполнены.

То есть, по-сути, это механизм SureBackup для инфраструктуры реплик, которого уже давно ждали пользователи Veeam Backup and Replication. Также там будут работать техники U-AIR (восстановление объектов приложений) и песочница On-Demand-Sandbox.

Напомним, как работают технологии виртуальных лабораторий Veeam:

• Для задачи выделяется хост-сервер ESXi или Hyper-V
• На этом хосте создается отдельный виртуальный коммутатор
• Специальный виртуальный модуль (Proxy Appliance) соединяется с виртуальным коммутатором для обеспечения сетевой связи изолированной тестовой лаборатории и внешней среды.
• Запрошенные виртуальные машины запускаются из файлов бэкапа напрямую, с использованием технологии vPower

То есть, к машинам становится возможен доступ извне для тестирования работоспособности сервисов приложений, но сами эти машины никогда не смогут соединиться с серверами внешней среды и полностью изолированы от производственного окружения.

Созданная технология верификации работоспособности реплик по аналогичной схеме называется SureReplica. При этом есть несколько приятных моментов:

• DR-сайт можно задействовать как под задачи тестирования реплик, так и частично использовать сервисы виртуальных машин. Например, в таких изолированных окружениях можно тестировать новые групповые политики перед их применением в производственной среде. То есть, все это можно использовать в качестве стейджинга.
• Функции Virtual Lab теперь включают поддержку Distributed Virtual Switch (DVS), что позволяет создавать изолированные лаборатории, задействующие несколько хост-серверов.
• Реплики находятся на обычных дисках (без сжатия и не в архивах), что значит, что это будет работать намного быстрее, чем при тестировании резервных копий, которые запускаются напрямую из бэкапов.

Более подробно о функциях виртуальных лабораторий для реплик виртуальных машин можно узнать по этой ссылке. Продукт Veeam Backup and Replication 7 будет выпущен в третьем квартале 2013 года.

Ну а тех из вас, кто хочет узнать побольше о новом продукте, приглашаем на совместный вебинар Veeam Software и Microsoft: Hyper-V в Windows Server 2012 и Veeam Backup & Replication.

В самом конце прошлой недели компания VMware выпустила обновление своей серверной платформы виртуализации - VMware vSphere 5.1 Update 1. Напомним, что версия vSphere 5.1 вышла еще летом прошлого года, поэтому апдейт продукта назрел уже давно.

Из официального списка новых возможностей VMware vSphere 5.1 Update 1:

• Поддержка новых гостевых ОС, приведенных в списке совместимости VMware.
• Исправления ошибок, приведенные здесь.

Надо сказать, что после vSphere 5.1 Update 1, следующие гостевые ОС НЕ будут поддерживаться со стороны VMware (этот релиз пока их поддерживает):

• Windows NT
• Все 16-битные версии Windows и DOS (Windows 98, Windows 95, Windows 3.1)
• Debian 4.0 и 5.0
• Red Hat Enterprise Linux 2.1
• SUSE Linux Enterprise 8
• SUSE Linux Enterprise 9 младше SP4
• SUSE Linux Enterprise 10 младше SP3
• SUSE Linux Enterprise 11 младше SP1
• Ubuntu releases 8.04, 8.10, 9.04, 9.10 и 10.10
• Все релизы Novell Netware
• Все релизы IBM OS/2

Самые интересные исправления ошибок ожидают пользователей в подсистеме работы с хранилищами:

1. Наконец-то при выполнении операции Storage vMotion можно полноценно поменять имя виртуальной машины (то есть, целиком - вместе с виртуальными дисками).

Об этом мы уже писали вот тут. Наконец-то это заработало. На сервере vCenter идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:

provisioning.relocate.enableRename со значением true

2. Увеличенный VMFS Heap Size.

Об этом параметре мы уже писали вот тут:

Он применяется не только к VMFS3, но и VMFS5. Теперь вот что поменялось:

• VMFS Heap может расти до 640 МБ вместо 256 МБ в прошлом релизе. Это позволяет подключать к хосту ESXi совокупный объем хранилищ до 60 ТБ.
  
• Размер кучи выставляется дефолтно 640 МБ для новых установок и сохраняется на уровне уже имеющегося значения для апгрейдов с предыдущих версий.
• Появился новый параметр, позволяющий гарантировать размер кучи - VMFS3.MinHeapSizeMB. Но его нельзя выставить больше, чем 255 МБ (однако она может продолжать расти до 640 МБ).

3. WWNN и WWPN для адаптеров FC HBA отображаются в vSphere Web Client корректно.

Раньше там отображалась бурда в виде ноликов на конце (см. тут). Теперь это поправлено.

Кроме всего этого, появилась хорошая статья KB 2037630, описывающая порядок обновления различных компонентов виртуальной инфраструктуры, построенной на продуктах VMware:

Там же - очень полезная табличка со ссылками:

Скачать VMware vSphere 5.1 Update 1 можно по этой ссылке.

Те из вас, кто пользуется услугами облачного IaaS-хостинга Amazon AWS, наверняка знают, что у этого сервис-провайдера есть решение Storage Gateway, позволяющее организовать гибридную модель хранения данных предприятия, а именно - частично или полностью хранить данные инфраструктуры виртуальных машин VMware vSphere в облачном хранилище Amazon S3.

Теперь же решение Storage Gateway поддерживает не только гипервизор VMware ESXi, но и хранилища платформы Microsoft Hyper-V.

Storage Gateway представляет собой виртуальный модуль (Virtual Appliance), размещенный в виде ВМ на хостах ESXi или Hyper-V, который предоставляет стандартный интерфейс iSCSI и выступает в качестве таргета для хост-серверов с виртуальными машинами (в общем случае поддерживается доступ различных приложений). Работа Storage Gateway возможна в двух режимах:

• Gateway-Cached Volume — в рамках этой архитектуры вы создаете тома для виртуальных хранилищ и монтируете их как iSCSI-устройства для хост-серверов. Виртуальный модуль кэширует данные и сохраняет их в облаке Amazon S3, при этом в инфраструктуре заказчика хранятся только кэшированные данные, которые наиболее часто оказываются востребованными.
• Gateway-Stored Volume — в такой архитектуре все данные виртуальных машин хранятся локально, в рамках инфраструктуры заказчика, а Storage Gateway периодически создает снапшоты (инкрементально) и передает данные отличий от базового образа в облако Amazon S3. Это создает хорошие возможности для сценариев Disaster Recovery.

Storage Gateway передает данные в S3 через защищённый SSL-канал. Более подробно с технической точки зрения о решении можно узнать тут и тут.

С началом поддержки Hyper-V в Storage Gateway компания Amazon вступает в прямую конкуренцию с Microsoft, которая в прошлом году приобрела компанию StorSimple, занимавшуюся тем же самым (только у них это программно-аппаратный комплекс) - предоставлением облачных хранилищ через онпремизные сервисы, размещенные на площадке заказчика (cloud-integrated storage).

Стоимость сервисов Amazon Storage Gateway можно узнать на этой странице.

На страницах vSphere Blog обнаружилась интересная статья Вильяма Лама про патчи, накатываемые на гипервизор VMware ESXi. Приведем здесь основные выдержки, которые могут оказаться полезными при обслуживании виртуальной инфраструктуры VMware vSphere.

Итак, для начала приведем структуру разделов на диске установленной копии ESXi:

Основное отличие от традиционной ОС в VMware ESXi - это то, что все файлы, необходимые гипервизору, хранятся в разделе фиксированного объема (Primary Boot Bank - 250 МБ). Альтернативный Boot Bank такого же размера необходим на случай отката к предыдущей версии ESXi, вне зависимости от того был ли произведен Update (накатывание патчей) или Upgrade (накатывание новой версии ESXi).

Если мы произведем апгрейд ESXi 5.0 на версию 5.1, то структура банков поменяется следующим образом:

Хотя это на самом деле даже и не так - ESXi 5.0 останется в прежнем банке, а загрузчик (Boot Loader) будет указывать уже на альтернативный банк, где разместится ESXi 5.1.

Когда происходит накатывание патча на ESXi - меняется весь банк (основной или альтернативный), поэтому патчи так много весят (по сути обновляется весь основной дистрибутив):

Но в этом есть и преимущество - размер раздела для банка фиксирован и установка ESXi не разрастается со временем при установке новых апдейтов и апгрейдах. Кстати, обратите внимание, что под патчем написано его влияние на систему после установки.

Следующий момент: являются ли патчи кумулятивными, то есть содержат ли они все предыдущие обновления ESXi? Да, все патчи содержат в себе предыдущие, поэтому нет необходимости накатывать их последовательно. Скачать патчи VMware ESXi можно с Patch Portal.

Далее, мы видим, что у патча есть список Bulletin List с суффиксом BG (Bug Fix). Есть также и SG-бюллетени обновлений по безопасности (Security). Оба этих типа бюллетеней могут обновлять как основной банк (base), так и пакеты VMware Tools (драйверы и прочее). Кроме того, в бюллетенях содержатся обновления драйверов устройств для самого сервера ESXi.

SG-бюллетень содержит только обновления подсистемы безопасности, а BG-бюллетени могут содержать новый функционал, исправления ошибок и, опять-таки, обновления, касающиеся безопасности.

Наконец, каждый бюллетень состоит из VIB-пакетов, о структуре которых Вильям хорошо рассказал вот тут. Список установленных VIB-пакетов на хосте ESXi можно узнать командой:

# esxcli software vib list

Будет выведено что-то вроде:

Name              Version                     Vendor Acceptance Level Install Date
----------------- --------------------------- ------ ---------------- ------------
ata-pata-amd      0.3.10-3vmw.500.0.0.469512  VMware VMwareCertified  2012-05-04
ata-pata-atiixp   0.4.6-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-cmd64x   0.2.5-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-hpt3x2n  0.3.4-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04

О том, как накатывать патчи на ESXi из консоли мы уже писали вот тут, также об этом рассказано в KB 2008939.

Не так давно мы писали о том, что компания VMware выпустила черновик своего регулярно обновляемого руководства по обеспечению безопасности VMware vSphere 5.1 Security Hardening Guide. На днях, после двухмесячных публичных обсуждений, вышла окончательная версия документа vSphere 5.1 Security Hardening Guide с примечаниями и правками от комьюнити.

На различных вкладках документа Excel можно найти сведения о защите следующих компонентов инфраструктуры vSphere:

• Виртуальные машины
• Хосты ESXi
• Виртуальные сети
• Сервер управления vCenter Server и его БД.
• Сервер vCenter Web Client
• Сервер единой аутентификации vCenter SSO
• Виртуальный модуль vCenter Virtual Appliance (VCSA), правда всего 3 пункта
• Средство обновления vCenter Update Manager

В отличие от предыдущих версий документа, категорий стало несколько больше, а пункты в них стали как-то поконкретнее. Также отметим, что теперь появилась централизованная страничка, где будут собраны все Hardening Guides (почему-то там нет руководства по VMware View):

http://vmware.com/go/securityguides

Традиционно к руководящим инструкциям по обеспечению безопасности и защите виртуальной среды VMware vSphere прилагается лог изменений документа.

Не так давно мы уже писали о накладных расходах на виртуализацию по памяти для виртуальных машин на платформе VMware vSphere, а сегодня поговорим о виртуальных ПК, которые предъявляют дополнительные требования к объему памяти сверх выделенного на обеспечение работы различных графических режимов в гостевой ОС.

Для начала отметим, что на платформе VMware Horizon View 5.2 появились следующие изменения по сравнению с предыдущими версиями в плане графических режимов виртуальных ПК:

• Horizon View 5.2 не позволяет установить 24-битную цветовую палитру, теперь используется только 32-битная.
• Horizon View 5.2 позволяет устанавливать разрешения только 1680×1050, 1920×1200 и 2560×1600. Дефолтным является 1920×1200.

Теперь о накладных расходах по памяти для виртуальных машин.

3D Software Rendering отключен

В этом случае расходы дополнительной памяти сервера на виртуальный ПК зависят от используемого разрешения и количества мониторов для виртуальной машины (значения приведены в мегабайтах):

Как вы знаете, в ESXi 5.0 появились возможности VMX Swap, которые позволяют создать swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте. Он в разы уменьшает использование физической памяти на Overhead виртуальных машин в случае недостатка ресурсов.

Затраты хранилищ (в мегабайтах) на создание второго *.vswp файла для механизма VMX Swap рассчитываются следующим образом:

Как мы видим, для некоторых виртуальных ПК может потребоваться более полугигабайта дополнительного дискового пространства.

3D Software Rendering включен

Для виртуальных ПК отдельно или в пределах пула можно установить объем видеопамяти (VRAM, не путать с vRAM) доступный гостевой системе, что влияет на накладные расходы на виртуализацию.

В этом случае дополнительно требуемая физическая память будет рассчитываться как 64 МБ + 16 дополнительных МБ на каждый монитор.

Что касается SWAP-файла, то требуемый для него объем существенно выше, чем в первом случае. Он зависит от выделенной видеопамяти:

То есть, в некоторых случаях дополнительные затраты на хранилище отдельной виртуальной машины могут достигать 2 ГБ. Чтобы это все учитывать при планировании инфраструктуры виртуальных ПК, можно воспользоваться калькулятором от Andre Leibovici, по материалам которого и написана эта заметка.